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Abstract 


This document describes how to adapt the Session Description Protocol 
(SDP) to express one or more source addresses as a source filter for 
one or more destination "connection" addresses. It defines the 
syntax and semantics for an SDP "source-filter" attribute that may 
reference either IPv4 or IPv6 address(es) as either an inclusive or 
exclusive source list for either multicast or unicast destinations. 
In particular, an inclusive source-filter can be used to specify a 
Source-Specific Multicast (SSM) session. 


1. Introduction 


The Session Description Protocol [SDP] provides a general purpose 
format for describing multimedia sessions in announcements or 
invitations. SDP uses an entirely textual data format (the US-ASCII 
subset of [UTF-8]) to maximize portability among transports. SDP 
does not define a protocol, but only the syntax to describe a 
multimedia session with sufficient information to discover and 
participate in that session. Session descriptions may be sent using 
any number of existing application protocols for transport (e.g., 
Session Announcement Protocol (SAP), SIP, Real Time Streaming 
Protocol (RTSP), email, and HTTP). 


Typically, session descriptions reference an IP multicast address for 


the "connection-address" (destination), though unicast addresses or 
fully qualified domain names (FQDNs) MAY also be used. The "source- 
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filter" attribute defined in this document qualifies the session 
traffic by identifying the address (or FQDN) of legitimate sources 
(senders). The intent is for receivers to use the source and 
destination address pair(s) to filter traffic, so that applications 
receive only legitimate session traffic. 


Receiver applications are expected to use the SDP source-filter 
information to identify traffic from legitimate senders, and discard 
traffic from illegitimate senders. Applications and hosts may also 
share the source-filter information with network elements (e.g., with 
routers using [IGMPv3]) so they can potentially perform the traffic 
filtering operation further "upstream," closer to the source(s). 


The "source-filter" attribute can appear at the session level and/or 
the media level. 


1.1. Motivation 


The purpose of a source-filter is to help protect receivers from 
traffic sent from illegitimate source addresses. Filtering traffic 
can help to preserve content integrity and protect against Denial of 
Service (DoS) attacks. 


For multicast destination addresses, receiver applications MAY apply 
source-filters using the Multicast Source Filter APIs [MSF-API]. 
Hosts are likely to implement these APIs using protocol mechanisms to 
convey the source filters to local multicast routers. Other 
"upstream" multicast routers MAY apply the filters and thereby 
provide more explicit multicast group management and efficient 
utilization of network resources. The protocol mechanisms to enable 
these operations are beyond the scope of this document, but their 
potential provided motivation for SDP source-filters. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [REQMNT]. 


3. The "source-filter" Attribute 


The SDP source-filter attribute does not change any existing SDP 
syntax or semantics, but defines a format for additional session 
description information. Specifically, source-filter syntax can 
prescribe one or more unicast addresses as either legitimate or 
illegitimate sources for any (or all) SDP session description 
"connection-address" field values. 
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Note that the unicast source addresses specified by this attribute 
are those that are seen by a receiver. Therefore, if source 
addresses undergo translation en route from the original sender to 
the receiver - e.g., due to Network Address Translation (NAT) or some 
tunneling mechanism - then the SDP "source-filter" attribute, as 
presented to the receiver, will not be accurate unless the source 
addresses therein are also translated accordingly. 


The source-filter attribute has the following syntax: 


a=source-filter: <filter-mode> <filter-spec> 


The <filter-mode> is either "incl" or "excl" (for inclusion or 
exclusion, respectively). The <filter-spec> has four sub-components: 


<nettype> <address-types> <dest-address> <src-list> 


A <filter-mode> of "incl" means that an incoming packet is accepted 

only if its source address is in the set specified by <src-list>. A 
<filter-mode> of "excl" means that an incoming packet is rejected if 
its source address is in the set specified by <src-list>. 


The first sub-field, <nettype>, indicates the network type, since SDP 
is protocol independent. This document is most relevant to the value 
"IN", which designates the Internet Protocol. 


The second sub-field, <address-types>, identifies the address family, 
and for the purpose of this document may be either <addrtype> value 
"TIP4" or "IP6". Alternately, when <dest-address> is an FQDN, the 
value MAY be "*" to apply to both address types, since either address 
type can be returned from a DNS lookup. 


The third sub-field, <dest-address>, is the destination address, 
which MUST correspond to one or more of the session’s "connection- 
address" field values. It may be either a unicast or multicast 
address, an FQDN, or the "*" wildcard to match any/all of the 
session’s "connection-address" values. 


The fourth sub-field, <src-list>, is the list of source 
hosts/interfaces in the source-filter, and consists of one or more 
unicast addresses or FQDNs, separated by space characters. 


The format and content of these semantic elements are derived from 


and compatible with those defined in [SDP]. For more detail, see 
Appendix A of this document. 
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3.1. Processing Rules 


There are a number of details to consider when parsing the SDP 
source-filter syntax. 


The <dest-address> value in a "Source-filter" attribute MUST 
correspond to an existing <connection-field> value in the session 
description. The only exception to this is when a "*" wildcard is 
used to indicate that the source-filter applies to all 
<connection-field> values. 


When the <dest-address> value is a multicast address, the field value 
MUST NOT include the sub-fields <ttl> and <number of addresses> from 
the <connection-address> value. If the <connection-address> 
specifies more than one multicast address (in the <number of 
addresses> field), then a source filter, if any, for each such 
address must be stated explicitly, using a separate "a=source-filter" 
line for each address (unless a "*" wildcard is used for 
<dest-address>). See section 3.2.4 for an example. 


When the <addrtype> value is the "*" wildcard, the <dest-address> 
MUST be either an FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 
address). See section 3.2.6 for an example. 


As has always been the case, the default behavior when a source- 
filter attribute is not provided in a session description is that all 
traffic sent to the specified <connection-address> value should be 


accepted (i.e., from any source address). The source-filter grammar 
does not include syntax to express either "exclude none" or "include 
able 


Like the standard <connection-field> described in [SDP], the location 
of the "source-filter" attribute determines whether it applies to the 
entire session or only to a specific medium (i.e., "session-level" or 
"media-level"). A media-level source-filter will always completely 
override a session-level source-filter. 


A "source-filter" need not be located at the same hierarchy level as 
its corresponding <connection-field>. So, a media-level 
<source-filter> can reference a session-level <connection-field> 
value, and a session-level "source-filter" can be applied to all 
matching media-level <connection-field> values. See section 3.2.3 
for an example. 


An SDP description MUST NOT contain more than one session-level 
"source-filter" attribute that covers the same destination address, 
or more than one media-level "source-filter" attribute that covers 
the same destination address. 
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There is no specified limit to the number of entries allowed in the 
<src-list>; however, there are practical limits that should be 
considered. For example, depending on the transport to be used for 
the session description, there may be a limit to the total size of 
the session description (e.g., as determined by the maximum payload 
in a single datagram). Also, when the source-filter is applied to 
control protocols, there may be a limit to the number of source 
addresses that can be sent. These limits are outside the scope of 
this document, but should be considered when defining source-filter 
values for SDP. 


3.2. Examples 


Here are a number of examples that illustrate how to use the source- 
filter attribute in some common scenarios. We use the following 
session description components as the starting point for the examples 
to follow. For each example, we show the source filter with 
additional relevant information and provide a brief explanation. 


<session-description> = 
v=0 
o=The King <Elvis@example.com> 
s=Elvis Impersonation 
i=All Elvis, all the time 
u=http://www.example.com/ElvisLive/ 
t=0 0 
a=recvonly 


<media-description 1> = 
m=audio 54320 RTP/AVP 0 


<media-description 2> = 
m=video 54322 RTP/AVP 34 


3.2.1. Source-Specific Multicast Example 
Multicast addresses in the Source-Specific Multicast [SSM] range 
require a single unicast sender address for each multicast 
destination, so the source-filter specification provides a natural 
fit. In this example, a session member should receive only traffic 
sent from 192.0.2.10 to the multicast session address 232.3.4.5. 


<session-description> 


c=IN IP4 232.3.4.5/127 
a=source-filter: incl IN IP4 232.3.4.5 192.0.2.10 


<media-description 1> 
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This source-filter example uses an inclusion list with a single 
multicast "connection-address" as the destination and single unicast 
address as the source. Note that the value of the connection-address 
matches the value specified in the connection-field. 


Also note that since the connection-field is located in the session- 
description section, the source-filter applies to all media. 


Furthermore, if the SDP description specifies an RTP session (e.g., 
its "m=" line(s) specify "RTP/AVP" as the transport protocol), then 
the "incl" specification will apply not only to RTP packets, but also 
to any RTCP packets that are sent to the specified multicast address. 
This means that, as a side effect of the "incl" specification, the 
only possible multicast RTCP packets will be "Sender Report" (SR) 
packets sent from the specified source address. 


Because of this, an SDP description for a Source-Specific Multicast 
(SSM) RTP session SHOULD also include an 


a=rtcp-unicast 


attribute, as described in [RTCP-SSM] (section 10.1). This specifies 
that RTCP "Reception Report" (RR) packets are to be sent back via 
unicast. 

3.2.2. Unicast Exclusion Example 


Typically, an SDP session <connection-address> value is a multicast 
address, although it is also possible to use either a unicast address 
or FQDN. This example illustrates a scenario whereby a session 
description indicates the unicast source address 192.0.2.10 in an 
exclusion filter. In effect, this sample source-filter says, 
"destination 192.0.2.11 should accept traffic from any sender 
*except* 192.0.2.10." 


<session-description> 


c=IN IP4 192.0.2.11 
a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10 


<media-description 1> 
3.2.3. Multiple Session Address Example 
This source-filter example uses the wildcard "*" value for 


<dest-addr> to correspond to any/all <connection-address> values. 
Hence, the only legitimate source for traffic sent to either 
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232.2.2.2 or 232.4.4.4 multicast addresses is 192.0.2.10. Traffic 
sent from any other unicast source address should be discarded by the 
receiver. 

<session-description> 

a=source-filter: incl IN IP4 * 192.0.2.10 

<media-description 1> 

c=IN IP4 232.2.2.2/127 

<media-description 2> 

c=IN IP4 232.4.4.4/63 


3.2.4. Multiple Multicast Address Example 


In this example, the <connection-address> specifies three multicast 
addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3. The first and third 


of these addresses are given source filters. However, in this 
example the second address - 224.2.1.2 - is *not* given a source 
filter. 


<session-description> 
c=IN IP4 224.2.1.1/127/3 
a=source-filter: incl IN IP4 224.2.1.1 192.0.2.10 
a=source-filter: incl IN IP4 224.2.1.3 192.0.2.42 
<media-description 1> 
3.2.5. IPv6é Multicast Source-Filter Example 
This simple example defines a single session-level source-filter that 
references a single IPv6 multicast destination and source pair. The 
IP multicast traffic sent to FFOE::11A is valid only from the unicast 
source address 2001:DB8:1:2:240: 96FF:FE25:8EC9. 


<session-description> 


c=IN IP6 FFOE::11A/127 
a=source-filter incl IN IP6 FFOE::11A 2001:DB8:1:2:240: 96FF:FE25: 8EC9 


<media-description 1> 
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3.2.6. IPv4 and IPv6 FODN Example 


This example illustrates use of the <addrtype> "*" wildcard, along 
with multicast and source FQDNs that may resolve to either an IPv6 or 
IPv4 address, or both. Although typically both the multicast and 
source addresses will be the same (either both IPv4 or both IPv6), 
using the wildcard for addrtype in the source filter allows asymmetry 
between the two addresses (so an IPv4 source address may be used with 
an IPv6é multicast address). 


<session-description> 
c=IN IP4 channel-1.example.com/127 


c=IN IP6 channel-1.example.com/127 
a=source-filter: incl IN * channel-l.example.com src-l.example.com 


<media-description 1> 
3.3. Offer-Answer Model Considerations 


The "source-filter" attribute is not intended to be used as an 
‘offer’ in an SDP offer-answer exchange [OFFER], because sets of 
source addresses do not represent /’/capabilities’ or ’limitations’ of 
the offerer, and because the offerer does not, in general, have a 
priori knowledge of which IP source address(es) will be included in 
an answer. While an answerer may include the "source-filter" 
attribute in his/her answer (e.g., to designate a SSM session), the 
answerer SHOULD ignore any "source-filter" attribute that was present 
in the original offer. 


4. Interoperability Issues 


Defining a list of legitimate sources for a multicast destination 
address represents a departure from the Any-Source Multicast (ASM) 
model, as originally described in [IGMPvl]. The ASM model supports 
anonymous senders and all types of multicast applications (e.g., 
many-to-many). Use of a source-filter excludes some (unknown or 
undesirable) senders, which lends itself more to one-to-many or few- 
to-few type multicast applications. 


Although these two models have contrasting operational 
characteristics and requirements, they can coexist on the same 
network using the same protocols. Use of source-filters do not 
corrupt the ASM semantics but provide more control for receivers, at 
their discretion. 
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5. Security Considerations 


See [SDP] for security considerations specific to the Session 
Description Protocol in general. The central issue relevant to using 
source address filters is the question of address authenticity. 


Using the source IP address for authentication is weak, since 
addresses are often dynamically assigned and it is possible fora 
sender to "spoof" its source address (i.e., use one other than its 


own) in datagrams that it sends. Proper router configuration, 
however, can reduce the likelihood of "spoofed" source addresses 
being sent to or from a network. Specifically, border routers are 


encouraged to filter traffic so that datagrams with invalid source 
addresses are not forwarded (e.g., routers drop datagrams if the 
source address is non-local) [FILTERING]. This, however, does not 
prevent IP source addresses from being spoofed on a Local Area 
Network (LAN). 


Also, as noted in section 3 above, tunneling or NAT mechanisms may 
require corresponding translation of the addresses specified in the 
SDP "source-filter" attribute, and furthermore, may cause a set of 
original source addresses to be translated to a smaller set of source 
addresses as seen by the receiver. 


Use of FQDNs for either <dest-address> or <src-list> values provides 
a layer of indirection that provides great flexibility. However, it 
also exposes the source-filter to any security inadequacies that the 
DNS system may have. If unsecured, it is conceivable that the DNS 
server could return illegitimate addresses. 


In addition, if source-filtering is implemented by sharing the 
source-filter information with network elements, then the security of 
the protocol(s) that are used for this (e.g., [IGMPv3]) becomes 
important, to ensure that legitimate traffic (and only legitimate 
traffic) is received. 


For these reasons, receivers SHOULD NOT treat the SDP "source-filter" 


attribute as being its sole mechanism for protecting the integrity of 
received content. 
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6. IANA Considerations 


As recommended by [SDP] (Appendix B), the new attribute name 


"source-filter" has been registered with IANA, 


as follows: 


July 2006 


The following contact information shall be used for all registrations 


included here: 


Contact: Ross Finlayson 


email: finlayson (at) live555.com 


phone: +1-650-254-1184 


SDP Attribute ("att-field"): 


Attribute name: source-filter 

Long form: Source Filter 

Type of name: att-field 

Type of attribute: Session level or media level 

Subject to charset: No 

Purpose: See this document 

Reference: This document 

Values: See this document, and registrations below 
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Appendix A. Source-Filter Attribute Syntax 


This appendix provides an Augmented BNF [ABNF] grammar for expressing 
an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast 
source addresses. It is intended as an extension to the grammar for 
the Session Description Protocol, as defined in [SDP]. Specifically, 
it describes the syntax for the new "source-filter" attribute field, 
which MAY be either a session-level or media-level attribute. 


The "dest-address" value in each source-filter field MUST match an 
existing connection-field value, unless the wildcard connection- 
address value "*" is specified. 


source-filter = "source-filter" ":" SP filter-mode SP filter-spec 
; SP is the ASCII ’space’ character 
: (0x20, defined in [ABNF]). 


Tezi" 7 ming" 
; either exclusion or inclusion mode. 


filter-mode 


filter-spec = nettype SP address-types SP dest-address SP src-list 
; nettype is as defined in [SDP]. 


address-types = "*" / addrtype 
"x" for all address types (both IP4 and IP6), 
; but only when <dest-address> and <src-list> 
R reference FQDNs. 
; addrtype is as defined in [SDP]. 


dest-address = "x" / basic-multicast-address / unicast-address 
"x" applies to all connection-address values. 
; unicast-address is as defined in [SDP]. 


src-list = *(unicast-address SP) unicast-address 
; one or more unicast source addresses (in 
F standard IPv4 or IPv6 ASCII-notation form) 
; or FQDNs. 
; unicast-address is as defined in [SDP]. 


basic-multicast-address = basic-IP4-multicast / basic-IP6-multicast 
/ FQDN / extn-addr 
; i.e., the same as multicast-address 
; defined in [SDP], except that the 
; /<ttl> and /<number of addresses> 
; fields are not included. 
; FQDN and extn-addr are as defined 
: in [SDP]. 
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basic-IP4-multicast = ml 3( "." decimal-uchar ) 
; ml and decimal-uchar are as defined 
; in [SDP]. 

basic-IP6-multicast = hexpart 


; hexpart is as defined in [SDP]. 
Authors’ Addresses 


Bob Quinn 
BoxnArrow.com 

31 Caldwell Road 
Waltham, MA 02453 


Phone: +1-781-577-1539 


EMail: rcq@boxnarrow.com 


Ross Finlayson 

Live Networks, Inc. 

650 Castro St., suite 120-196 
Mountain View, CA 94041 


EMail: finlayson@live555.com 


Quinn, et al. Standards Track [Page 13] 


RFC 4570 SDP Source Filters July 2006 


Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is provided by the IETF 
Administrative Support Activity (IASA). 


Quinn, et al. Standards Track [Page 14] 


